1. Field of the Invention
The invention relates to a mechanism, that is a system and method, for breaking live lock and supporting group keying and re-keying in routing system of networks, in particular IP based networks such as the Internet.
2. Description of the Related Art
Routing protocols exchange network-prefixes (routes) during their routing update process. Commonly used deployed routing protocols are Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Intermediate system and Intermediate Systems (IS-IS) for intra-domain routing and Border Gateway Protocol (BGP) for inter-domain routing. A recommended intra-domain routing protocol is OSPF; it uses both multicast and unicast channels for their update and flooding process. None of the routing protocols are designed with inbuilt security mechanism. For OSPF, security extensions were added later. These security extensions were not widely used due to lack of automatic mechanism and deployment issues. For example no automatic re-keying is provided for, and MD5 (Message Digest 5) which is now being used for authentication in OSPFv2 does not provide adequate security. Deployments are based on manual keying that leads to problems especially against replay attacks such as described in an article by Jerome Etienne, “Flaws in packet's authentication of OSPFv2”, IETF Internet-Draft, “http://off.net/˜jme/ietf/draft-etienne-ospfv2-auth-flaws-00.html”. Group keying and multicast security are still open security problems.
Routing protocols like OSPF use multicast and unicast protocols for exchanging LSA (Link State advertisements). OSPF supports three different mechanisms to use security extensions, namely no security at all, security-using password based scheme, or cryptographic checksum based on Message Digest 5 (MD5) for authentication. MD5 authentication provides higher security than plain text authentication. MD5 authentication uses a key ID that allows the router to reference multiple passwords, making password migration easier and more secure.
OSPFv3 (OSPF version 3) does not have fields for security. When OSPFv3 is run on top of IPv6, all the security mechanisms to IPv6 are leveraged. Routing tables for OSPFv2 (version 2) and OSPFv3 are separate and they do not share anything in common. For IPv6 Authentication header is mandatory, IPv6 expects some mechanism to be present for establishing the Security Association (SA) and applying the SA credentials to the flows. It may use Internet Protocol security/Internet Key Exchange (IPsec/IKE) or any other security protocol to provide keys and SA information's.
OSPF uses multicast on a shared segment to reduce the traffic overhead, and uses point-to-point communication for non-shared segment or network. For IPv6 authentication is mandatory, yet currently there is no defined scheme to perform secured group communication. Moreover in OSPF the problem expands in different directions on shared network as follows:
First, OSPF routers are supposed to send a “hello” packet to their neighboring peers in multicast channel. The hello packet is used to inform the neighboring routers and to perform a discovery process, and needs also to be authenticated. This creates a problem. Before sending the packet, OSPF routers need the keys and credentials to generate and authenticate the packets.
The problem is that the OSPF routers should know in advance whom all the other OSPF routers in the same segment are and what keys to be used to authenticate their packets. This is a so-called live lock situation. A hello message is the only way for an OSPF node to advertise that it is an OSPF node and wants to participate in the OSPF protocol. Only legitimate routers are supposed to send hello packets and to participate in the OSPF protocol.
A further problem is how should the OSPF routers create the SA's (Security Associations) for inbound and outbound traffic when they do not know their neighbors.
OSPF routers, after receiving hello packet from the neighbors, will cooperatively perform designation router and backup designation routers selection process. All these messages have to be authenticated. This is currently performed by manual keying. The messages are pre-configured and the operations are made. OSPF supports very little resistance against replay protection and with manual keying there is no replay protection with IPv6/IPv4. OSPF is an interior routing protocol and is used internally within a single administrative domain. To detect internal attacks, Intrusion Detection Systems are deployed at hot-spots with high traffic. Since OSPF is with a domain, the only way to defeat against such attack is by placing Intrusion detection systems on all the segments but it may be costly for network operator to modify almost every routing element.
A structure in accordance with the above description is shown in, and described with regard to FIG. 1. FIG. 1 illustrates OSPF message exchange in shared segment. Routers R1 to R6 are routers connected in a shared LAN. The routers may be a Designated Router (DR) and a Backup Designated Router (BDR). As shown in FIG. 1, router R6 sends a hello packet, or/and it may send router LSA update message in multicast channel. The designated router DR provides the summary LSA in another multicast address which all the OSPF routers R1 to R6 in the LAN will receive. The backup designated router BDR becomes active when designated routers DR fail. OSPFv3 leverages all authentication mechanism to IPv6. Currently there is no automatic support for secured group communication and how to authenticate the OSPF packets. Due to these shortcomings, there is insufficient security.
OSPFv2 and OSPFv3 are proposed to perform manual keying for authenticating routers/nodes. This has several severe limitations. For example, there is no provision of automatic re-keying, no replay protection, and there is no way to make sure that only OSPF legitimate nodes are exchanging the hello protocol message.